home *** CD-ROM | disk | FTP | other *** search
/ Aminet 37 / Aminet 37 (2000)(Schatztruhe)[!][Jun 2000].iso / Aminet / dev / lang / sofa.lha / sofa / smalleiffel / man / c_code.txt < prev    next >
Text File  |  2000-03-25  |  5KB  |  104 lines
  1.  
  2.                          About the generated C code
  3.                                       
  4.    People who want or have to code part of their applications and/or
  5.    libraries in C should really limit themselves to the clean interfaces
  6.    provided by [1]Cecil or the [2]external mechanism. This page mentions
  7.    some facts you should be aware of before you start.
  8.    
  9.    Generated type names
  10.    
  11.    First and above all, SmallEiffel generates one unique type name in the
  12.    C code for each living type present in the Eiffel code. This type is
  13.    of the form Txyz where xyz represents the number corresponding to the
  14.    name of the type, including its parameters in the case of generic
  15.    types. (More details about this in our [3]research papers). When you
  16.    compile your application, you can find them in a mangling table,
  17.    somewhere in the C code, which looks like this:
  18. D 2  T1489 R BOOLEAN_CONSTANT 210,253
  19. A 1  T945  R BIT_CONSTANT 945
  20. A*1  T218  R TAG_NAME 218
  21. A 1  T602  R TYPE_BIT_1 602
  22.  
  23.    But don't use this information ! The mangling table is only valid for
  24.    one specific compilation of one specific application with one specific
  25.    compiler and specific libraries...
  26.    
  27.    Indeed, when computing a type code, collisions may occur, and affect
  28.    this process. Thus, the number (and name) corresponding to each type
  29.    depends not only on the type name, but also on the order in which they
  30.    are compiled. That is, on the application and libraries compiled...
  31.    They also depend on the compilation mode used, and the version of the
  32.    compiler you're using. So what is T145 now may become T234 the next
  33.    time you compile...
  34.    
  35.    Consequently, do not, ever, rely on the type numbers in the generated
  36.    C code, because they are not constant ! (Except for a few ones which
  37.    have a fixed, hard-coded name). So don't bother writing in your own C
  38.    code things such as new123 or T456, because the only thing we
  39.    guarantee in this case is that your code shall break one day or
  40.    another...
  41.    
  42.    The mangling table
  43.    
  44.    OK, so now you understand why you cannot use type numbers, but you
  45.    still want to know what those things in the mangling table mean. :)
  46.    
  47.    First, a big caveat. Although it hasn't changed a lot and has been
  48.    very stable for quite some time now, the mangling table coding may
  49.    change in the future ! As I'm writing these lines, we have no plans to
  50.    change it, and we prefer keeping it the way it is. But once again, we
  51.    do not commit ourselves to the current representation.
  52.    Here is excerpts of a mangling table which cover all the possible
  53.    cases (taken from some compile_to_c.h):
  54. A 1  T220  R E_DEBUG 220
  55. A 6  T326  R FIXED_ARRAY[RUN_FEATURE] 389,384,367,352,326,53
  56. D 2  T166  R BOOLEAN_CONSTANT 169,168
  57. A*1  T215  R E_ENSURE 215
  58. A 1  T37   E NATIVE_ARRAY[STRING] 37
  59.  
  60.    Each mangling table entry comprises 7 fields:
  61.    
  62.    Liveness
  63.           The first field shows whether the type is Dead or (A)Live, that
  64.           is whether instances of this type are ever created at run-time.
  65.           (Ok, it should have been L, instead of A...)
  66.           
  67.    Tagless
  68.           When the second character on a line is a star *, it marks an
  69.           untagged type, that is a type on which there is no late binding
  70.           but only static calls. Note that the type inference algorithm
  71.           used in SmallEiffel increases the number of such types.
  72.           
  73.    # of live subtypes
  74.           Number of concrete, live descendants of the type (including
  75.           itself). It is thus the number of items in the last field.
  76.           
  77.    Type mangled name
  78.           The type name in the C code. As [4]explained above, the ID
  79.           number varies.
  80.           
  81.    Reference
  82.           
  83.    Is the type a Reference or an Expanded one?
  84.           
  85.    Full type name
  86.           Self-explanatory...
  87.           
  88.    Live subtypes list
  89.           A comma-separated list of type IDs listing all the live
  90.           descendants of the current type (including itself, if it is a
  91.           live one).
  92.           
  93.                                    [Line]
  94.    Copyright © Dominique COLNET and Suzanne COLLIN - [5]<colnet@loria.fr>
  95.                      Last update: 05 May 1999, by OZ. 
  96.  
  97. References
  98.  
  99.    1. file://localhost/home/colnet/SmallEiffel/man/man/cecil.html
  100.    2. file://localhost/home/colnet/SmallEiffel/man/man/external.html
  101.    3. file://localhost/home/colnet/SmallEiffel/man/papers/papers.html
  102.    4. file://localhost/home/colnet/SmallEiffel/man/man/c_code.html#generated-type-ids
  103.    5. mailto:colnet@loria.fr
  104.